An OpenFlow (OF for short) protocol is a forwarding/control separation protocol proposed by Stanford University in the United States at 2008. An external control plane entity adopts the OF protocol to control a forwarding plane device to implement various forwarding logics, while the main function of the forwarding plane device is to execute controlled forwarding according to a flow table issued by an OF controller. The OF protocol is further evolved to become a software defined network (SDN for short) technique, i.e., various complicated network applications may be implemented adopting software programming at a control plane, e.g., an SDN is configured to implement an evolved packet system (EPS for short)/general packet radio service (GPRS) network. The EPS network is a 3rd generation partnership project (3GPP for short) defined 4th generation mobile communication network, and the GPRS network is a 3GPP defined 3rd generation mobile communications network.
FIG. 1 is an architecture diagram where an SDN is employed to implement an EPS/GPRS network according to the relevant art. The architecture mainly comprises User Equipment (UE for short), a(n) (evolved) Universal Terrestrial Radio Access Network ((E)UTRAN for short), a core network, a controller, and an internet, wherein the UE is a communication terminal; the (E)UTRAN is a radio access network, and the inside of the (E)UTRAN is composed of an evolved NodeB (eNodeB) or a NodeB; and the core network, i.e., a software defined Evolved Packet Core (EPC for short) network, is a core network portion of the EPS, and all the Unified Gateways (UGWs for short) in the core network are general gateway devices, and the role thereof is controlled by control signaling from an SDN controller. For example, with regard to an IP connection of certain UE, a unified gateway UGW-1 serves as a serving gateway (SGW for short) or a serving GPRS support node (SGSN for short); a UGW2 serves as a packet data network gateway (P-GW for short) or a gateway GPRS support node (GGSN for short); and a UGW3 serves as a non-3GPP access gateway or an evolved packet data gateway (ePDG for short). In such way, between the (E)UTRAN and the UGW-1, between the UGW-1 and the UGW-2, and between the UGW-2 and the UGW-3 are all interfaces based on a GPRS tunnel protocol-user plane (GTP-U for short) protocol. In other words, the GTP-U protocol must be supported between a UGW and an (e)NB, between a UGW and a UGW, or between a UGW and a traditional GTP network element.
The GPRS tunnel protocol (GTP for short) is a set of protocols defined by 3GPP, which is divided into a GPRS tunnel protocol-controller plane (GTP-C for short) protocol and a user plane protocol GTP-U. The GTP-U is a protocol used for data encapsulation and forwarding between gateways. In addition, the GTP-U further has a set of self session detection mechanism: detecting a path and detecting a path state by sending a GTP-U Echo Request message and Echo Response message to the opposite end, and the specific flow is as shown in FIG. 2, comprising the steps as follows:
step S202, a UGW1 sends an echo request message to a UGW2.
One UGW, such as the UGW 1, serves as a GTP endpoint 1 to send an echo request message to a UGW which serves as a GTP endpoint 2, such as the UGW2, and the UGW 1 starts a timer t1 after sending the message.
A target address of the echo request message is an address of the GTP endpoint 2; a destination port number of a user datagram protocol (UDP for short) is set as 2152; a tunnel endpoint identifier (TEID for short) is all-zero; a source address is an address of the UGW1 itself; and a source port number is any configured port. A sequence number (SN for short) is an initial value, such as 0 or adding 1 to the sequence number of the last echo request message.
Step S204, the UGW2 sends an Echo response message to the UGW1.
The GTP endpoint 2, i.e., the UGW2, after receiving the echo request message, sends an Echo Response message to the opposite end, wherein a target address of the Echo Response message is an address of the GTP endpoint 1, a destination port number of the UDP is set as the source port number of the echo request message in step S202, the TEID is all-zero, a source address is an address of the UGW2 itself, a source port number is the destination port number of the echo request message in step S202, and an SN is the SN of the echo request message.
The GTP endpoint 1, i.e., the UGW1, after receiving the Echo Response message, ends the timer t1, and starts a timer t2.
If the timer t1 times out but the Echo Response message is not received, the GTP endpoint 1 may re-send the echo request message, the format and content of the message being the same as those of the echo request message sent at the first time, and start the timer t1 again. If the echo response message has not been received after t1 times out again, then the operation above is repeated. After operations for N1 times, if there is still no echo response message received, then it is considered that this link is blocked, and the GTP endpoint 1 performs a relevant operation locally, such as deleting GTP context.
After the timer t2 times out, the GTP endpoint 1 may send another echo request message, the SN of the message equals to the SN of the echo request message of the last time add 1, and start the timer t1. Steps S202 and S204 above are repeated in subsequent operations.
step S206, the UGW2 sends an echo request message to the UGW1.
The GTP endpoint 2, i.e., the UGW2, sends an echo request message to the GTP endpoint 2, i.e., the UGW1.
step S208, the UGW1 sends an echo response message to the UGW2.
The GTP endpoint 1, i.e., the UGW 1, receives the echo request message and responds with an echo response message. The specific operations are the same as step S202 and step S204, while the difference lies in that the GTP endpoint 1 exchanges the role with the GTP endpoint 2.
The GTP endpoint 1 and the GTP endpoint 2 respectively detect respective echo request and echo response message pairs, and the message pair detected in step S202 and step S204 has no dependent relationship with the message pair detected in step S204 and step S206.
The GTP principle introduced above is applicable to the existing gateway/NodeB of 3GPP, and the GTP endpoint generally refers to any network element of an eNB, an NB, an SGW, a P-GW, an ePDG; a credit access network gateway, an SGSN, or GGSN, etc. in a 3GPP network. When an SDN is configured to implement an EPC, logics related to a control plane are all implemented on an SDN controller. A UGW, serving as a forwarding device, only has a forwarding function and a very simple logical control function. Therefore, how to implement GTP session (referring in particular to a GTP-U) detection, i.e., how to use an echo request message and an echo response message, is a problem to be solved.
With regard to the problem in the relevant art that logic of a user plane and logic of a control plane are unclear during detection of a data link between GTP endpoints, there is no effective solution proposed at present.